Fix MCP proxy "Refetch Server Info" and let it reuse stored credentials

Problem

Clicking Refetch Server Info on an MCP proxy's Backend Connection tab always failed:

{
  "status": "error",
  "code": "VALIDATION_FAILED",
  "message": "Provide either url or proxyId, not both."
}

The UI sent { url, proxyId } on every unedited refetch, but MCPServerInfoFetchRequest
declared the two mutually exclusive (oneOf) and FetchServerInfo rejected the pair
outright. The refetch button was broken for every proxy.

Fixing the immediate error exposed a second, worse gap. auth.value is write-only — it
comes back to the browser masked as ****** — so the only way to refetch with a stored
credential was proxyId, which also forces the stored URL. That left no way to answer
"does my edited endpoint work?" without first re-typing a credential the user may never
have had a copy of. Editing just the URL dead-ended in:

Enter the authentication header value to refetch with the updated endpoint or header.

What changed

url and proxyId are no longer mutually exclusive. Which fields are present now selects
the target and the credential independently, giving three valid shapes:

auth still may never accompany proxyId: whenever a proxy is referenced its stored auth
is authoritative, and an override is rejected rather than silently ignored. A request with
neither url nor proxyId is still rejected.

The supplied URL is used verbatim — no path normalization, no /mcp appended — the
same invariant the proxyId-only flow already guarantees and that
TestFetchServerInfoRefetchUsesStoredURLVerbatim guards.

Backend — platform-api

• FetchServerInfo (internal/service/mcp.go): dropped the "not both" rejection. When
  proxyId is given, the stored URL and credential are resolved as before, then a
  supplied url overrides the URL only. The auth + proxyId and neither-field
  rejections are unchanged.
• MCPServerInfoFetchRequest (resources/openapi.yaml): oneOf → anyOf (at least one
  of url/proxyId) plus not: required: [proxyId, auth], which expresses "auth never
  with proxyId" without also forbidding the new pair. Field descriptions updated.

Frontend — portals/ai-workspace

• ExternalServersOverview.handleRefetch: rewritten to pick the shape by which credential
  the fetch runs with rather than by "is anything edited". Ordered so a typed credential
  always wins, a cleared/absent auth header fetches unauthenticated, and an edited endpoint
  with an untouched credential takes the new { url, proxyId } path.
• The remaining dead end is narrower and now says something actionable: renaming the auth
  header while the value stays masked has no valid shape (proxyId would resolve the old
  header name too), so it asks for the value or a save first.
• MCPServerInfoFetchRequest (src/utils/types.ts): modelled as a union so auth +
  proxyId fails to compile rather than failing at runtime.

Testing

• go test ./internal/service/ — passes.
  • TestFetchServerInfoSuppliedURLWithStoredCredential (new): asserts the supplied URL is
    contacted verbatim and the proxy's stored credential header still rides along.
  • TestFetchServerInfoRejectsAmbiguousTargets: the "both url and proxyId" case is
    removed (now valid); the auth-with-proxyId and neither-field cases stay.
• tsc --noEmit — no new errors.
• Cypress 005-mcp-backend-connection-refetch.cy.js updated: TC-98/TC-100 asserted the old
  url-present shape and now assert url is omitted; TC-102 (new) covers the
  { url, proxyId } path — edited endpoint, credential left masked, no auth on the wire.
  Not executed locally (needs a running stack).

Reviewer notes

Scope of the relaxation. fetchMCPProxyServerInfo is granted by ap:mcp_proxy:read
or ap:mcp_proxy:manage, while updateMCPProxy needs ap:mcp_proxy:update or
manage. So a read-only caller can now have the server attach a proxy's stored
credential to a request aimed at a URL they supply. This was a deliberate call for
simplicity over a same-origin restriction on the supplied URL. Note the capability is not
entirely new — a caller holding update could already reach the same outcome in two steps,
since preserveMCPUpstreamAuthValue carries the stored secret across a URL-only save
(asserted by TC-101) — but it is new at the read tier. If that tier matters, the smallest
follow-up is to require ap:mcp_proxy:update for the url + proxyId shape specifically.

Also in this branch: LLM provider upstream auth defaults to none. Commit e24cb2bbd
had changed the gateway-import path to default an absent upstream auth block to other
(defaultUpstreamAuthToOther); that is reverted here, so mapLLMUpstreamYAMLToModel
defaults to none as before. The AI Workspace provider-creation form is aligned with it:
picking a credential-bearing auth type but leaving the API key empty now records none
rather than other (ServiceProviderNew.tsx). An explicitly chosen other or none is
still preserved either way. Independent of the MCP work above and reviewable separately.